Subject: DLUR stuff #4 (REQDISCONT response from DLUR)

From: [email-masked]
Date: Mon, 17 Jun 96 11:16:07 EST

>> Interim status - I asked someone in NCP how its BF handled REQDISCONT
>> The answer was that it didn't - the REQDISCONT flows were sent on the
>> SSCP-PU session between the host and the PU with no intervention by
>> NCP.

>> So I've asked someone in VTAM how its SSCP handles REQDISCONT; when I
>> get an answer back, I'll pass it on.

Turns out VTAM does not generate a response to REQDISCONT - it just
begins the deactivation procedure requested.  Therefore the flows in
the DLUR architecture reference for REQDISCONT are correct as is.

Ed Tremblay

---

From: Dario Calia <[email-masked]>
Date: Thu, 27 Jun 1996 10:21:04 -0700

Hello Ed,

I believe you have miss-interpreted the request.  The issues is not
whether a REQDISCONT demands a response, but the RU which included the
REQDISCONT had the RH bits sent indicating a definite response was required.

So, what should a DLUR node do when it receives a REQDISCONT?

I would like to propose that when the REQDACTPU +RSP comes back from DLUS
that DLUR generate the necessary response, when needed, to the dependent
device.

At this point, DLUS sends the responses on any SSCP-xx DFR flows.  However,
I would hate to have DLUS send a +RSP to the REQDACTPU and a +RSP to the
RU send by the dependent device.

Thanks, Dario

---

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Thu, 27 Jun 96 13:50:58 EDT

My guiding design assumption here is that the DSPU should see the
same behavior when attached to a DLUR BF as it does when attached to an
NCP BF.

What I learned, and didn't communicate clearly enough in my previous
two notes, was what the DSPU sees when attached to an NCP BF.  Even if
the DSPU requests a definite response to REQDISCONT, the subarea SSCP
does not return one, but instead begins sending the deactivation RUs
(DACTLU, DACTPU, DISCONTACT) to the NCP BF and then on to the DSPU.

The DLUS should (and does) behave the same way as the subarea SSCP,
i.e., no response to REQDISCONT sent.

I checked with NCP to see if its BF introduced a RSP(REQDISCONT) and it
does not.  Therefore, the DLUR BF should not generate a RSP(REQDISCONT)
either.

Have you run across any DSPUs hanging awaiting RSP(REQDISCONT)?  When
DSPUs see either a DACTPU or DACTLU, they're supposed to handle them
right away and not queue them awaiting RSP(REQDISCONT).

Ed

---

From: Dario Calia <[email-masked]>
Date: Thu, 27 Jun 1996 15:17:39 -0700

Hello Ed,

Again, you are not understanding my request.  I am NOT talking
about a RSP(REQDISCONT). Immagine any RU.  Immagine now that
the DRx bits are set requesting a definite response.  Regardless,
of whether the RU has an associated RSP(RU), the SNA protocol
requests a definite response -- typically a simple RH indicating
a positive or negative response.

If you take a look at the SSCP-PU/LU flows which occur between
the dependent PU/DLUR/DLUS, you will note that DLUS correctly
processes most of the RUs requesting Definite Responses.  That
is, DLUS sends an RH indicating a postive/negative response.

However, when a CM/2 sends a REQDISCONT and indicates definite
response, DLUS fails to send a definite response.  Again,
I am not implying that there is such a beast as a RSP(REQDISCONT),
but simply an RH indicating positive/negative response.

More comments below ...

  >(DACTLU, DACTPU, DISCONTACT) to the NCP BF and then on to the DSPU.

I do not believe this is correct.  I have traces which clearly show
the NCP sending an RH indicating a positive response.

  >i.e., no response to REQDISCONT sent.

See above.

  >does not.  Therefore, the DLUR BF should not generate a RSP(REQDISCONT)

I never implied a RSP(REQDISCONT).  Simply talking about a response to
a definite response request.  See my discussion above.

  >right away and not queue them awaiting RSP(REQDISCONT).

CM/2 fails to complete the orderly shutdown as requested.

Ciao, Dario